home *** CD-ROM | disk | FTP | other *** search
- Path: rcp6.elan.af.mil!rscernix!danpop
- From: danpop@mail.cern.ch (Dan Pop)
- Newsgroups: comp.lang.c
- Subject: Re: printing pid_t...
- Date: 21 Feb 96 10:28:33 GMT
- Organization: CERN European Lab for Particle Physics
- Message-ID: <danpop.824898513@rscernix>
- References: <4gcv6f$6jf@cisunix1.dfci.harvard.edu>
- NNTP-Posting-Host: ues5.cern.ch
- X-Newsreader: NN version 6.5.0 #7 (NOV)
-
- In <4gcv6f$6jf@cisunix1.dfci.harvard.edu> gotd@jimmy.harvard.edu (Godfrey Degamo) writes:
-
- >Hello. Sorry to bother you with this question. I don't know
- >if this belongs in comp.unix.programmers or here.
-
- comp.unix.programmer would have been probably better, but the answer
- doesn't involve any (other) Unix-specific features, so here it goes:
-
- [the c.l.c purist is kindly asked to mentally replace pid_t by size_t :-)]
-
- >Anyways, I want to read and write pid_t to a text file. The problem
- >is how is pid_t type defined? As an int, long, unsigned int or
- >unsigned long.
-
- If there was a unique definition for pid_t, pid_t wouldn't have existed
- in the first place. The purpose of these types is to hide the real
- definition, which can differ from system to system.
-
- >Can I be safe to assume unsigned long and use %lu for printing and
- >scanning?
-
- This is a safe assumption, as long as you deal only with text streams.
- If you need to read/write pid_t objects from/to a binary stream, you
- don't need any assumptions about pid_t:
-
- FILE *fp;
- pid_t pid;
-
- fread(&pid, sizeof pid, 1, fp);
-
- Dan
- --
- Dan Pop
- CERN, CN Division
- Email: danpop@mail.cern.ch
- Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
-